\documentclass[a4paper,10pt]{article}
\usepackage{graphicx}

\title{Plan van Aanpak\\\small Gedistribueerde Systemen\\\small Team 8}
\author{Harm Dermois, Wadie Assal, Ravish Gopal\\\small 0527963, 6398693, 0426822}

\begin{document}
\maketitle

\section{Inleiding}
Voor het practicum Gedistribueerde Systemem maken wij een chatserver. De
server is onderdeel van een groep servers die samen een gedistribueerd
chat-netwerk vormen. De
server moet rekening houden met meerdere andere servers en meerdere clients
die eraan verbonden zijn. Ook heeft de server een continue verbinding met de
control server.

\section{Implementatie}
Als implementatietaal is gekozen voor Java. Deze taal kennen wij allemaal het
best, daarom lijkt het ons het makkelijk hierin te programmeren. Zo loop je 
minder snel tegen beperkingen aan van het programmeren in een nieuwe taal.
Het is een gecompileerde taal, daarom denken wij dat het snel genoeg zal zijn
voor ons programma.

\section{Analyse}
Het protocol kent een boomstructuur, zoals te zien in de onderstaande figuur.
\includegraphics[width=10cm]{NetwerkDia.jpg}
\\
Dit betekent dat elke server slechts een 
verbinding heeft met zijn parent server, maar meerdere verbindingen kan hebben 
die door (andere) child servers met hem worden aangegaan. Het is belangrijk
dat de boomstructuur behouden blijft en er geen cykels ontstaan, omdat er dan
een kans bestaat dat berichten blijven rondgaan in de cykel en hun bestemming
niet bereiken. Het protocol heeft acties die voorzien in de opbouw en het 
behoud van de boomstructuur.
Om de status van het netwerk en de verbindingen bij te houden worden alle gegevens 
opgeslagen in een datastructuur.\\\\
Elke server heeft dus 4 soorten verbindingen:
\begin{itemize}
\item verbinding met parent: \'e\'en verbinding
\item verbinding met control server: \'e\'en verbinding
\item verbinding met childservers: veel verbindingen
\item verbinding naar clients: veel verbindingen
\end{itemize}
Er zijn zeven berichttypes. Client-server, server-client en server-server
worden gebruikt voor het onderhoud van het netwerk en voor het versturen
en bezorgen van de berichten van de ene client naar de andere. Controlserver-server
en server-controlserver berichten worden gebruikt voor het toevoegen van
een nieuwe server aan het al bestaande netwerk, of voor het hergroeperen van
de servers als er een server wegvalt. Ook zijn er controlserver-client en client-controlserver
berichten, deze zijn voor onze implementatie niet zo van belang.
Het protocol is beperkt tot basis functionaliteit. Er zijn wel een aantal 
zaken die problemen kunnen veroorzaken. Omdat er met UDP verbindingen gewerkt 
wordt, is er kans dat berichten niet aankomen. Het protocol voorziet nu niet in 
controle daarvaan. Een oplossing hiervoor zou kunnen zijn dat een server bij 
elk bericht het volgnummer van dat bericht terugstuurt en dat nieuwe berichten 
alleen worden verstuurd als de respons-volgnummer ontvangen is. In het geval dat 
het niet zo is, wordt het oude bericht opnieuw verstuurt. 
Wat ook voor problemen kan zorgen is het wegvallen van een server. In dat geval 
is er geen verbinding tussen delen van het netwerk. Er kunnen dan allerlei problem 
zich voordoen, zoals een naamwijziging, of het geval dat twee clients met 
dezelfde naam zich aanmelden. Dit kan pas worden verholpen nadat de nieuwe pings verstuurd zijn en het 
antwoord wegblijft, waarna het netwerk zich kan herstructureren. 
Het protocol is dus wel functioneel, maar niet volwassen.
\\\\
Hieronder hebben we een aantal voorbeelden uitgewerkt van het protocol:\\
\begin{figure}[ht]
    \begin{minipage}[b]{0.6\linewidth}
        \centering
        \includegraphics[scale=0.3]{Client.png}
    \end{minipage}
    \hspace{0.5cm}
    \begin{minipage}[b]{0.5\linewidth}
        \centering
        \includegraphics[scale=0.2]{Serverconnect.png}
    \end{minipage}
\end{figure}

\section{Ontwerp}
Onze implementatie zal worden opgedeeld in verschillende modules. Een duidelijk
klasse diagram van de structuur is te zien in de onderstaande afbeelding, samen
met een diagram van het verloop van de berichten:\\\\
\includegraphics[width=7cm]{design.jpg}
\\
Omdat we met UDP werken, is er \'e\'en 'verbinding' waar de data over ontvangen 
wordt, voor het versturen is er geen verbinding, het bericht wordt op goed geluk 
uitgezonden. 
\\
Er zijn twee soorten acties die de server onderneemt. Een is als de server een
bericht binnenkrijgt. Daarop moet een actie ondernomen worden. De ander is
als de server geplande acties onderneemt, zoals pingen naar servers en clients.
Uiteraard draaien beide in verschillende threads.

\subsection{Main}
De main klasse start de server. Hij maakt een socket aan waar data over verzonden 
kan worden en start alle threads. De main kan ook afvangen wanneer een thread een 
fout geeft, stuurt de main een stopsignaal naar de andere threads.

\subsection{Listen}
Hier worden inkomende berichten afgevangen en doorgestuurd naar de message queue van 
de message handler.

\subsection{Message handler}
In deze klasse worden beslissingen genomen. Als er bijvoorbeeld een ping binnenkomt, 
wordt er aan de queue van de message creator doorgegeven dat een pongbericht moet 
worden uitgezonden. Als er een tekstbericht binnenkomt, wordt het juiste bericht 
voor alle ontvangers toegevoegd aan de queue van de messagecreator, die ze weer 
uitzendt.

\subsection{Message creator}
De message creator haalt berichten op uit zijn queue en zendt het bericht uit met de 
gegevens van de ontvanger.

\subsection{Pinger}
De pinger is een aparte thread die zelf om een bepaalde tijd voor alle entries in 
de database controleert of hij moet pingen. Alle verbonden servers en clients
moeten regelmatig gepingd worden om te kijken of ze nog actief zijn. De pinger 
geeft geeft de data van de te pingen apparaten aan de queue van de message creator, 
die het bericht eruit stuurt.

\subsection{DB en logger}
De database wordt gebruikt om de gegevens van alle verbindingen op te slaan, 
zodat berichten met de juiste gegevens kunnen worden verzonden, en de pinger 
zijn werk kan doen. Verder is er een logger klasse die door alle klasses kan 
worden gebruikt om te handelingen of berichten te loggen. Dit is vooral handig 
voor het debuggen.

\subsection{Threads}
Er zijn zullen 4 threads lopen in ons programma:
\begin{enumerate}
\item Listener: luistert naar inkomende berichten en voegt deze toe aan de msg handler queue. 
\item Msg Handler: leest de message handler queue uit en wikkelt deze af.
\item Send: leest de message creator queue uit en verstuurt de berichten over de juiste socket.
\item Pinger: loopt de DB af en kijkt naar welke apparaten er gepingd moet worden.
\end{enumerate}

\section{Werkverdeling}
\begin{itemize}
\item verslag: Ravish
\item klasses:
    \begin{itemize}
        \item Main + Listen: Harm
        \item Log + Pinger: Ravish
        \item Message Creator + Database: Wadie
        \item Message Handler: allemaal
    \end{itemize}
\end{itemize}
Wij hebben een google project aangemaakt, zodat we met een subversion repository 
kunnen werken.
\\\\
Om zo snel mogelijk te kunnen testen maken we eerst de Main, Listen, Log en 
Message Handler klasse. Deze klasses programmeren we initieel niet volledig, maar 
alleen de benodige functies om berichten te kunnen ontvangen en verzenden. Daarna 
voegen we de overige functionaliteiten toe.

\section{Planning}
\begin{itemize}
\item week 1: plan van aanpak, werkverdeling
\item week 2: plan van aanpak aanpassen, maken van interfaces van de klasses, main + log
\item week 4: implementeren Listen, Msg Handler, Msg Creator, DB en Pinger
\item week 5: afmaken klasses, test en bugfixes
\item week 6: stable versie, test, verslag
\item week 7: eind test
\end{itemize}
\end{document}
